查看原文
其他

备份方案规划设计将遇到8个问题

备份软件能否良好的运行,前期的规划设计非常重要,本文整理了一些该方面的知识供读者参考。


1. 如何界定备份和归档这两者的区别?

有些用户经常容易把备份和归档混淆,最初的需求不明确就会导致后期的实施方案走样,用起来各种问题,后期维护也是非常麻烦。

1. 先从对应场景来说

一般情况下,我们把用于恢复目的数据保留称作备份。这类数据一般变化较大,保留时限较短。仅仅是为了应对数据丢失来设计的。

而归档,一般对应的是长期存放,数据变化量相对较小,比较多的场景是基于法律法规要求的以年为单位的数据保留,应对的数据审查等操作。

2. 再从备份软件设计的角度来看

从备份软件的角度来看,各个备份软件在各自的系统中都有备份和归档一说,而且主要还是针对文件系统备份的时候提及的较多,就TSM和NBU对比来看,TSM有backup和archive这样的名词,而NBU也有user backup和user archive这样的备份类型。

这里以TSM为例,如果是数据备份,备份软件里对应的有数据保留的活动版本、非活动版本、删除版本以及非活动版本和删除版本的保存期限等参数(copygroup的verexistes、verdelete、retextra、retonly四个参数)。能比较灵活的应对备份数据的各种需求点。

对应归档来说,没有非活动版本的概念,每个版本都是活动的,只能以时间来界定(copygroup的retver参数)。

针对刚刚谈到的归档和备份的区别,根据第一点提到的需求差别,可以灵活的选择即可,比如:

对于大多数的普通文件、sql数据库、IBM domino、MS exchange等数据保留都可以通过上面说的副本组参数来灵活配置。

对于db2和oracle分别由程序自身来控制,db2使用db2adutl,oracle使用rman。

当然,也有一些特殊情况,比如db2的归档日志存放,或者sap的数据保留也会用的归档模式,这里根据备份和归档的设计差别,也可以解释的通。

3. 最后从数据的特点来看

一般情况下数据变化大的建议用户选用备份;而数据基本不变化,且需要长期保留的数据我建议用户一次或者定期归档长时间保留。


2、备份、容灾如何去选择?

数据备份,是只针对业务数据进行备份,实时的也好,调度的也好,都备份的是业务中的数据或环境,用来在系统发生故障,硬件损坏,误操作等情况下恢复正确的数据或者业务环境的一种手段。数据备份一般会保存一定的周期,数据容灾是指建立一个异地的数据系统,为了保护数据安全和提高数据的持续可用性,两者其实实现的效果并不相同,一个是用来保证数据的安全性和正确性,一个是用来保证业务的实时性。如果你对你的业务和数据足够重视,那么至少线从数据备份做起,保证数据的基本安全,根据业务特点搭建容灾环境来保证业务的连续性,其实两者并不矛盾。

根据合规性检查的相关要求,比如财务系统是必须容灾加备份的,有的还要求备份到独立介质,异地存放等等,大部分容灾指的是异地数据备份,还未到自动业务切换,要达到业务级的容灾,倒不如做双活或者多活的数据中心,反而投入比单纯的容灾要值得。


3、备份数据保存多久?

需要根据业务而确定,如分为活跃数据,查询数据,冷数据等。备份策略是指综合备份类型和备份频率。如年度备份,季度备份策略,月度备份,周备份,天备份。

如果存储够,而且数据又不能确定是否有用,建议一直保存,如果不够,建议封存,如果需要找回以前的老数据,那就恢复一下。


4、针对企业现有的数据规模,如何规划存储类型、容量并设计合适的调度作业?

见过不少客户的备份环境,用起来资源紧张,捉襟见肘。有的是备份空间不足,被迫修改保留策略。有的是受限客观环境,通道不足导致备份窗口加长,最后备份失败。总而言之,大都是是初始规划设计方面准备不足,导致后期维护困难。可以从以下几个点来考虑:

1. 存储空间确认

首先应该先汇总,看看当前要需要备份的系统有多少套,每套大概有多少数据量,最终得到1个初步的数据总量;

其次,应该了解并估算整个备份环境的增长量,以及规划的年数。比如,初步估算所有的备份数据总量为5T,每年增长20%,规划5年周期。最后的总量应该是12.5T左右;

最后,要确认保存的周期或保存的版本数。比如,初步按3个版本保存,40T的容量应该是没问题的。

2. 根据存储空间初步确定设备选型

比如,如果使用物理带库,按LTO6的磁带来算,14盘磁带就够了,但是考虑到并置组、存储池以及其他考虑等冗余要求,需要再多设计一些磁带,比如20盘。然后再考虑到是否要需要需求磁带循环使用,那么磁带库的槽位数量必须要多于20个。

如果是虚拟磁带库,考虑到产品的重删功能,可以对应的降低有效容量的配置要求。或者如果是磁盘存储池并启用重删功能,也可以根据测试对应的降低要求。

3. 备份窗口的确定

和业务系统的负责人沟通,了解每个要备份的业务系统的最大备份窗口,根据备份窗口选择合适的备份方式。通过合理的配置优化备份窗口,比如,使用lanfree备份,增加驱动器等备份通道、使用性能更改的备份设备等方式。一般来讲,核心系统和数据量大的非核心系统要求要配置lanfree备份。并且,如果配置lanfree也要做好规划设计,比如,做好san规划,使得备份zone和普通存储zone分开,并且备份系统都要使用独立的hba卡或独立的hba卡接口。

4. 备份调度的确定

根据RPO和RTO和设计合理的备份调度周期,根据各个系统的备份窗口,合理的设计各个系统的备份时间。

5. 做好备份恢复测试,并设计相应的制度,定期进行备份演练。

这个反而是最关键的,搞了半天备份,关键的时候恢复不了,这个就要命了,这样血的教训太多了。


5、D2D2T是个什么东西?有哪些好处?什么情况下使用?

是不是经常听到什么虚拟带库、D2D2T等各种术语。虚拟带库有哪些好处?为什么不直接备到磁盘存储上。所谓的D2D2T又是个啥? 适合哪些场景?

数据由磁盘到磁盘再到磁带,我们一般称之为d2d2t,第二个D也可以理解为虚拟磁带库。第一个D近线存储,生产数据;第二个D离线存储,备份数据;T磁带库设备,离线数据。

传统的备份软件最初大都基于磁带库设计的,基于传统备份软件的备份架构已经非常成熟了,而且最近几年也再与时俱进,功能、性能及稳定性上都有了很大的进步。但是现有的企业环境数据量越来越大,业务类型也越来越复杂。对于物理磁带库来讲,最新的LTO7在容量和性能上有了很大的提升,顺序读写速度已经超过了sata磁盘,并且在离线保存方面还有很大的优势。但是在其他方面还有一些先天的劣势,比如数据恢复时的随机读写速度非常慢、重复数据删除、异地复制等等。

在这种情况下,作为中间层出现的磁盘或虚拟带库弥补了这个缺陷。D2D2T架构有如下好处:

1. 数据备份可以先到磁盘或虚拟带库上,在这一层可以得到良好的备份恢复速度,优化了备份恢复窗口,使用户得到一个非常好的RTO和RPO;

2. 备份到磁盘或vtl上的数据可以通过重复数据删除功能节省空间。重删可以由tsm来做,也可以直接基于vtl硬件来实现。

3. 可以实现其他一些基于硬件的高级功能,比如基于vtl的备份容灾(可参考liulei_oracle兄的案例分享1)。

4. 满足数据离线保存或出库需求,备份数据可以得到更高的冗余保护。可以将虚拟磁带库上的数据再次迁移或复制到物理磁带库一份。备份数据到物理带库这个操作可以基于备份软件来做,也可以基于虚拟磁带库本身来做,使用起来非常灵活。

综上,D2D2T在一些数据量大,备份要求高等需求场景下,有非常好的表现,可以考虑在对应的场景下使用。


6、如何选择备份软件?

在今天,主流的备份软件功能同质化,均能承担数据中心绝大部分数据备份工作。对于备份管理员,挑选一款适合自己使用习惯的备份软件尤为重要。在长期的备份系统设计与实施中,建议从三个方面考量:

1,基于个人维护习惯。适合个人维护习惯的软件,能够最大程度的契合对该软件的学习和使用成本,简单点说就是——上手难度。

2,基于方案需求。建议按照项目首要、次要、必要需求来定性挑选备份软件。再好的软件,无法解决当前问题那也白搭。备份系统相对复杂,且是一个成长型系统,在每个时期均有里程碑目标,只有一步一个脚印,系统才能健壮成长。因为涉及的方方面面多,在其建设初期需要收纳汇总各系统的情况和需求,最后集中考虑。作为备份系统的最终维护管理者,一定要明确当前的需求并分清层次,哪些是急需解决的,哪些是可以凑合的,哪些是不用着重考虑的。

3,基于产品售后。对于产品售后的定位,就和备份系统一样,一辈子都可能用不上几次,但要有用的时候若是没有,也是麻烦。对于主流的备份软件售后服务口碑也要了然于心,哪家服务不错哪家服务欠佳,任君挑选。

4、一切均以实际效果为准。挑选备份软件不能单纯依靠产品参数,不能听着吹得天花乱坠的性能就偏听偏信,综合而言,是骡子是马,拉出来溜溜。火车不是靠推的,牛皮也不是靠吹的。


7、如何设计磁带出库保存或异地恢复?

长时间的磁带保存方案如何设计,如果异地恢复又有什么值得注意的?

以NBU和两TSM款典型的备份软件来举例:

1. 如果使用NBU

方案1:VAULT, 对数据集备份到磁带中,然后从带库中弹出,做离线保存,可以把关键的数据运输到异地做导入恢复。

优点:便宜

缺点:要带库支持一定功能,并要长期人为去维护拿带子等

方案2:AIR(Automatic Image Replicate),AIR要求两个MSDP之间做数据的同步,这要求要一定的带宽和相应的磁盘做MSDP池。

优点:重复数据删除功能,同步效率高,可实现1对多,多对1的数据同步,自动化程度高。

缺点:价格贵,架构较复杂,处理问题也比较麻烦。

2. 如果使用TSM

TSM的出库有以下几种类型:

A. 普通的出库,即超长时间的保留导致的磁带数量越放越多,超出了磁带库的槽位数,所以需要定期的将已满的磁带取出。对应的命令:

update volume volume_name access=readonly
checkout libvolume library_name volume_name

checkout后取出存放即可。不用太在意标签的问题,如果后期有恢复或回调需求,直接做即可,会提示需要哪盘磁带,找到后checkin即可即可。

B. 长期保存为目的,不影响当前备份数据。

对于普通文件:generate backupset

对于Oracle、db2等数据库:export node到磁带即可

C. 基于多重保护目的。将磁带库设置为副本存储池。定期将主池的数据备份到副本池。然后按照步骤A来取带子,保存好即可。

D. 使用drm,相对于有个单独的数据库来记录出库磁带

关于磁带的保存,不管采用那种技术做磁带出库,都建议如下:

1,环境要求,避光防潮忌消磁,温度湿度适中,专柜存放。

2,存放标签要求,分门别类,标签写明:什么时间备份的什么系统的什么数据,保留至多久,用于什么目的。磁带编码有哪些,对应原备份系统哪些备份配置。

3,磁带出入库登记,没有的话弄丢磁带或找磁带的时候就只能哭了。

如果是基于TSM的异机恢复,分以下几种:

A. 普通恢复,从tsm中取出的磁带,需要tsm server才能读取。所以,需要先在异地恢复tsm server,需要用到tsm db备份,卷历史文件、设备配置文件等。恢复完tsm server后,才可以正常读取磁带

B. 仅异地恢复数据。只支持export和备份集方式的备份。上面出库步骤1和3类型的不支持。


8、最后,领导不重视数据备份怎么办?

既然不重视,必然有几方面的原因。

一种情况是外行领导内行,对于数据备份的认识不够,或者认为投资高,而有没有回报,导致轻视或者减少数据备份方面的投资。只有真正经历过数据事故的人和企业才会真切的体会到数据的重要性,没出过事自然不知切肤之痛。

一种情况是难以争取数据安全方面的费用,因为没有相关文件的明文规定,所以较难获得这方面的投资,如果有,那就是不做为了。大部分现在都有指导建议,只是备份的规模可能和投入有不少差距。做好合理的数据备份规划,提交审批都算尽责了。现在不重视的人越来越少了,还是乌纱帽要紧。

如果你多次申请都没有得到回复,那能做的就是尽量自保吧。作为运维人员,数据安全上你是第一责任人,出了问题肯定不会找领导,先找到你。如果真恢复不了,你就是替罪羊。所以数据备份不备份完全是运维人员的事。即使没有条件,你也应该自己有后路,有办法将损失降到最低,这是你的职责。

1.首先,利用手头的资源尽可能的做备份。做好安全,是竭尽权利的做好这些。

2.把提交的报告形成书面的文档。得到书面的回复。出了问题。没有你的责任。

3.准备好应急方案,出现问题后哪些可以补救,哪些补救不了。出问题之后领导知道痛了需要提交怎样的申请。


以上内容根据社区问答整理,分享者包括潘延晟、王巧雷、ttkanni等多位社区专家和会员


更多相关内容请点击阅读原文,有任何问题欢迎到社区提问


长按二维码关注公众号

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存